Skip to main content

Pomelo Modernization Initiative

Pomelo Application (Previously known as JDM Auto-Parts) is a Point of Sale application deployed on the product owner's terminal. Said application can handle the day-to-day task of the client's needs, but the client need to market their products to the digital world.

Existing flow Figure 1: The old system flow for transactions

Scopes and limitation​

The initiative is just to provide the client an internet channel to accept transactions automatically. However, to control the concurrent operations of local store and the digital one, stocks must be separated from each. This is part of the initial phase to ensure the modernization's effectivity.

Components​

The modernization goal is fairly simple; split the point of sale functions into workable microservices:

  • lookup-api: will contain the product details such as name, description.
  • stock-updater-svc: will contain the product's actual quantity, linked by product ID from the lookup-api.
  • pricing-api: will contain the product price. the reason for separating it with lookup is the future plan to track the price changes in said product.
  • transaction-api: this component will handle the transaction flow for each product. from translating the barcodeNo, to updating the transaction database.
  • storefront-ui the frontend application.

Other application(s) not exclusively written for this initiative is/are:

  • PUMA - a notification ecosystem to give an update towards the frontend via websocket about the status of current transaction.
warning

There is no real benefit for separating the pricing-api, and lookup-api. Product changes such as description, name, and pricing can be compounded into a single service that handles the monitoring.

Technologies used​

  • RabbitMQ: for real-time event-driven functionalities such as transaction notification, barcode translation, and stock updates. This technology was used instead of traditional RESTful communication to take advantage of the blocking mechanism of queues.
    warning

    I have to admit,at the time of this writing. the blocking mechanism might not scale at large volume of transactions.

  • Cassandra: Mainly used by PUMA notification. Cassandra is chosen over MariaDB given its write-over-read power. I had once tested its capability due to an exception that occured in backend where it wrote over 86k rows of data within a span of few minutes without breaking. In fact, the app broke first before Cassandra.
  • Spring Boot 3: I chose Spring Boot 3 due to its Java 17 support. I have strongly taken advantage of the Record feature over the course of my coding.
  • MariaDB: MariaDB is my default database of choice for local development, Given its open-source nature.
  • StompJS for Websockets: Instead of polling the backend continuously for results of any given transaction, I used WebSockets. WebSocket allow for a feature
  • React w/ Vite JS: Since Create-React-App was abandoned, Vite JS looks to be a good fit to explore.
  • antd: a component framework I used with the frontend for faster deployment.
  • NGINX: NGINX was used to slim down the frontend build from almost 2GB to a surprisingly 25MB size. Apart from that, it was used in my LAN Server as a reverse-proxy.
  • Docker: was used as containerization tool in my local. Docker Registry, a self-hosted registry for my images, and Portainer, a web-based UI for Docker are used. Containerization improves the deployment time with storage allocation as a tradeoff.